Fix up the synchronisation around grant table map track handles.
authorKeir Fraser <keir.fraser@citrix.com>
Wed, 27 May 2009 10:29:38 +0000 (11:29 +0100)
committerKeir Fraser <keir.fraser@citrix.com>
Wed, 27 May 2009 10:29:38 +0000 (11:29 +0100)
commita665dad568930584bd0b7ce916ca7682f8c46eaa
tree6081a8b54b273c99a0e342f7b8966f5591d3cb9c
parent07943d8e2dce64ae13b0bbf5f7caccd6b15c87a2
Fix up the synchronisation around grant table map track handles.
At present, we're not doing any at all, so if a domain e.g. tries to
do two map operations at the same time from different vcpus then you
could end up with both operations getting back the same maptrack
handle.

Fix this problem by just shoving an enormous lock around grant table
operations.  This is unlikely to be heavily contended, because netback
and blkback both restrict themselves to mapping on a single vcpu at a
time (globally for netback, and per-device for blkback), and most of
the interesting bits are already protected by the remote domain's
grant table lock anyway.

The unconteded acquisition cost might be significant for some
workloads.  If that were the case, it might be worth only acquiring
the lock only for multi-vcpu domains, since we only manipulate the
maptrack table in the context of one of the domain's vcpus.  I've not
done that optimisation here, because I didn't want to think about what
would happen if e.g. a cpu got hot-unplugged from a domain while it
was performing a map operation.

Signed-off-by: Steven Smith <steven.smith@citrix.com>
xen/common/grant_table.c
xen/include/xen/grant_table.h